The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also be inventions.
A client-server model is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and requesters of a resource or service, called clients. Often clients and servers communicate over a computer network on separate hardware, but both clients and servers may reside in the same system. Servers can execute server programs, await incoming requests for resources or services, and share their resources or services with clients that initiate communication sessions with the servers to request resources or services enabled by the executing server programs.
Examples of computer applications that use a client-server model include email and the World Wide Web (WWW). A server can host a database system that manages information in objects, such as a database system that stores records for each customer in a customer relationship management (CRM) database. An object is a digital entity that can store information, such as a customer's given name, family name, job title, employer name, street address, city, state, zip code, e-mail address, and phone number. Each instance of an object may be referred to as a record.
A client can call a server's application programming interface (API) to initiate a communication session with the server. The first time that a client calls to initiate a communication session with a server, the server may send a token to the client. A token, which may be referred to as an authorization token, can be a unique identifier that is generated and sent from a server to a client to authorize a communication session between the client and the server. A token is different from a user identifier (ID) in that communication sessions are typically short-lived, expiring after a preset time of inactivity that may be minutes or hours. A client may provide a token to continue an existing communication session with a server or to initiate a new communication session with a server. A server that is communicating with a client may enable the client to call on a third-party vendor's API to initiate a communication session with the third-party vendor. The third-party vendor can respond to such a request by sending a third-party authorization token to authorize a communication session between the client and the third-party vendor.
A third-party vendor's server can provide a client with the configuration file required to configure calls to the third-party vendor's API to initiate communication sessions with the third-party vendor's server, and to configure responses from such calls. For example, when a client registers with a third-party vendor's data service hosted by the third-party vendor's server, the server responds by providing the third-party vendor's configuration file that the client can use to configure calls to the third-party vendor's API, and to configure responses from the third-party vendor's API. In another example, after the third-party vendor's server changes the authentication mechanism specified by the third-party vendor's configuration file for calling the third-party vendor's API and receiving responses from the third-party vendor's API, the server sends the updated configuration file to the client because the client previously registered with the third-party vendor's data service. Consequently, the registered clients always have the most recently updated configuration files required to call the API for the third-party vendor's server, and to receive responses from the third-party vendor's server. A configuration file can be data that specifies an arrangement or a set-up, and which is stored in a computer's memory or on a storage device under a single identifying name. For example, a third-party vendor's configuration file can specify the API Uniform Resource Locator (URL), the request definitions, the response definitions, the content type, the response type, the retry interval, the unique name for the third-party vendor, the refresh interval if needed, the password header, and the authentication mechanism required for a call made to the third-party vendor's API and a response from the third-party vendor's API. Examples of authentication mechanisms include Oauth2, basic authentication, token based authentication, and configuration based custom authentication.